home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000119_icon-group-sender _Tue Mar 10 16:54:24 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  2KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id QAA19497
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Tue, 10 Mar 1998 16:54:20 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA13463; Tue, 10 Mar 1998 16:54:19 -0700
  7. From: gep2@computek.net
  8. Date: Tue, 10 Mar 1998 13:49:31 -0600
  9. Message-Id: <199803101949.NAA29177@axp.cmpu.net>
  10. Mime-Version: 1.0
  11. Content-Type: text/plain
  12. Content-Transfer-Encoding: 7bit
  13. Subject: Re: ICON and a "Java" implementation status
  14. To: icon-group@optima.CS.Arizona.EDU
  15. X-Mailer: SPRY Mail Version: 04.00.06.17
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18. Content-Length: 1390
  19.  
  20. >> He is still working on the Java implementation of Icon, as is Gregg Townsend
  21. > here, but it's not getting major attention.  The implementation is
  22. > complete and it works, but it doesn't run acceptably fast.
  23.  
  24. > (1) Perhaps Todd could release his code for the rest of the world to
  25. improve upon since he lacks the time.
  26.  
  27. I think it's amusing (in a sad sort of way) that the immediate reaction is that 
  28. "it's slow because of Todd's code, which needs improvement" instead of "it's 
  29. slow because of Java".  Other major projects which have been implemented in Java 
  30. (Corel's Office Suite for example) also had performance problems sufficient to 
  31. basically scuttle those, too... and those presumably had nothing related to Icon 
  32. in them.  :-)
  33.  
  34. > (2) Todd may have reached a fundamental performance limit that cannot be
  35. improved upon in this context, except by moving to compiled C++.  That
  36. may explain why Todd is presently working on a Java-->C converter.  If
  37. so, it argues again for an Icon-->C++ converter and against an
  38. Icon-->Java converter.
  39.  
  40. Honestly, I don't see a whole lot of reason for going to **either**.  Icon 
  41. (IMHO) works just FINE as it is.  Any reason for going Icon->Java, in whatever 
  42. case, has nothing to do with any anticipated PERFORMANCE improvement!
  43.  
  44. Gordon Peterson
  45. http://www.computek.net/public/gep2/
  46. Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
  47.  
  48.